Method and apparatus for use in a communications network

ABSTRACT

A method is disclosed for use by an Interrogating Call/Session Control Function (I-CSCF) of an IP Multimedia Subsystem (IMS). In the method, a Session Initiation Protocol (SIP) message is received by the I-CSCF, which the I-CSCF attempts to forward to a Serving Call/Session Control Function (S-CSCF) of the IMS assigned to provide services to a user. If the attempt is determined to have failed, the I-CSCF sends a message to a Home Subscriber Server (HSS) of the IMS to request capabilities information for selecting a S-CSCF, the request message also providing first information relating to the status of the assigned S-CSCF. On receipt of the capabilities information at the I-CSCF from the HSS, the I-CSCF selects a replacement S-CSCF to provide services to the user. Related methods are also disclosed for use by the HSS and S-CSCF.

TECHNICAL FIELD

The present invention relates to a method and apparatus for use in acommunications network, for example a Universal MobileTelecommunications System having an IP Multimedia Subsystem.

BACKGROUND

IP Multimedia services provide a dynamic combination of voice, video,messaging, data, etc. within the same session. By growing the number ofbasic applications and the media that it is possible to combine, thenumber of services offered to the end users will grow, and theinter-personal communication experience will be enriched. This will leadto a new generation of personalised, rich multimedia communicationservices, including so-called “combinational IP Multimedia” services.

The UMTS (Universal Mobile Telecommunications System) is a thirdgeneration wireless system designed to provide higher data rates andenhanced services to subscribers. UMTS is a successor to the GlobalSystem for Mobile Communications (GSM), with an important evolutionarystep between GSM and UMTS being the General Packet Radio Service (GPRS).GPRS introduces packet switching into the GSM core network and allowsdirect access to packet data networks (PDNs). This enables high-datarate packets switch transmissions well beyond the 64 kbps limit of ISDNthrough the GSM call network, which is a necessity for UMTS datatransmission rates of up to 2 Mbps. UMTS is standardised by the 3^(rd)Generation Partnership Project (3GPP) which is a conglomeration ofregional standards bodies such as the European TelecommunicationStandards Institute (ETSI), the Association of Radio Industry Businesses(ARIB) and others. See 3GPP TS 23.002 for more details.

The UMTS architecture includes a subsystem known as the IP MultimediaSubsystem (IMS) for supporting traditional telephony as well as new IPmultimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides keyfeatures to enrich the end-user person-to-person communicationexperience through the use of standardised IMS Service Enablers, whichfacilitate new rich person-to-person (client-to-client) communicationservices as well as person-to-content (client-to-server) services overIP-based networks. The IMS is able to connect to both PSTN/ISDN (PublicSwitched Telephone Network/Integrated Services Digital Network) as wellas the Internet.

The IMS makes use of the Session Initiation Protocol (SIP) to set up andcontrol calls or sessions between user terminals (or user terminals andapplication servers). The Session Description Protocol (SDP), carried bySIP signalling, is used to describe and negotiate the media componentsof the session. Whilst SIP was created as a user-to-user protocol, IMSallows operators and service providers to control user access toservices and to charge users accordingly. The 3GPP has chosen SIP forsignalling between a User Equipment (UE) and the IMS as well as betweenthe components within the IMS.

Specific details of the operation of the UMTS communications network andof the various components within such a network can be found from theTechnical Specifications for UMTS that are available fromhttp://www.3gpp.org. Further details of the use of SIP within UMTS canbe found from the 3GPP Technical Specification TS 24.228 V5.8.0(2004-03).

FIG. 1 of the accompanying drawings illustrates schematically how theIMS fits into the mobile network architecture in the case of a GPRS/PSaccess network (IMS can of course operate over other access networks).Call/Session Control Functions (CSCFs) operate as SIP proxies within theIMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF(P-CSCF) which is the first point of contact within the IMS for a SIPterminal; the Serving CSCF (S-CSCF) which provides services to the userthat the user is subscribed to; and the Interrogating CSCF (I-CSCF)whose role is to identify the correct S-CSCF and to forward to thatS-CSCF a request received from a SIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe address at which a SIP user identity can be reached. In 3GPP, when aSIP terminal performs a registration, the IMS authenticates the user,and allocates a S-CSCF to that user from the set of available S-CSCFs.Whilst the criteria for allocating S-CSCFs is not specified by 3GPP,these may include load sharing and service requirements. It is notedthat the allocation of an S-CSCF is key to controlling (and chargingfor) user access to IMS-based services. Operators may provide amechanism for preventing direct user-to-user SIP sessions which wouldotherwise bypass the S-CSCF.

During the registration process, it is the responsibility of the I-CSCFto select an S-CSCF if a S-CSCF is not already selected. The I-CSCFreceives the required S-CSCF capabilities from the home network's HomeSubscriber Server (HSS), and selects an appropriate S-CSCF based on thereceived capabilities. (It is noted that S-CSCF allocation is alsocarried out for a user by the I-CSCF in the case where the user iscalled by another party, and the user is not currently allocated anS-CSCF.) When a registered user subsequently sends a session request tothe IMS, the P-CSCF is able to forward the request to the selectedS-CSCF based on information received from the S-CSCF during theregistration process.

Within the IMS service network, Application Servers (ASs) are providedfor implementing IMS service functionality. Application Servers provideservices to end-users in an IMS system, and may be connected either asend-points over the 3GPP defined Mr interface, or “linked in” by anS-CSCF over the 3GPP defined ISC interface. In the latter case, InitialFilter Criteria (IFC) are used by an S-CSCF to determine whichApplications Servers should be “linked in” during a SIP Sessionestablishment. Different IFCs may be applied to different call cases.The IFCs are received by the S-CSCF from an HSS during the IMSregistration procedure as part of a user's User Profile. CertainApplication Servers will perform actions dependent upon subscriberidentities (either the called or calling subscriber, whichever is“owned” by the network controlling the Application Server). For example,in the case of call forwarding, the appropriate (terminating)application server will determine the new terminating party to which acall to a given subscriber will be forwarded. In the case that an IFCindicates that a SIP message received at the S-CSCF should be forwardedto a particular SIP AS, that AS is added into the message path. Once theSIP message is returned by the AS to the S-CSCF, it is forwarded ontowards its final destination, or forwarded to another AS if this isindicated in the IFCs.

As appreciated by the applicant, the IMS does not specify any procedureby which an IMS node advertises the adjacent nodes (or far end nodes)about a temporary unavailability due to, for example, a restart, localmaintenance operations such as software (SW) upgrades, and so on, andthe later recovery.

The lack of such a procedure can cause some interference in the usualfunction of the applications involved.

It is desirable to address the above-identified issue.

The following is a list of some of the previously-considered proceduresfor recovery situations:

-   -   GSM Restoration procedures: In this specification it is        described the methods by means of which nodes like HLR, VLR,        SGSN, GGSN restore user data after their loss of corruption. See        “3rd Generation Partnership Project; Technical Specification        Group Core Network; Restoration procedures (Release 6)” (3GPP TS        23.007 V6.1.0).    -   Radius Charging ON-OFF: When a Radius Charging client recovers        from an unavailability situation, it advertises the charging        server about the event so that the charging server closes all        sessions related with the affected client (i.e. those charging        sessions opened for users which use the affected client). See        RFC 2865 “Remote Authentication Dial In User Service (RADIUS)”.    -   MTP 3 Restart: once the MTP 3 layer recovers from a restart        (unavailability), it begins an advertising procedure toward the        adjacent nodes, so that they can reconfigure their routing        tables accordingly and notifies their respective users about the        event for taking the proper actions. See “Specifications of        Signalling System No. 7-Message transfer part; Signalling        network functions and messages”, ITU-T Recommendation Q.704.    -   SCCP Restart: similar to the MTP 3 Restart but at SCCP level and        advertising only the concerned subsystems.    -   M3UA Restart: Equivalent to the MTP 3 Restart but for SIGTRAN.    -   Diameter peer restart: This is detected with the DWR/DWA        messages specified in IETF RFC 3588.    -   Diameter application restart: This is indicated with the        Origin-State-Id AVP specified in IETF RFC 3588.

It is desirable to address the above-identified issue.

SUMMARY

According to a first aspect of the present invention there is provided amethod for use by an Interrogating Call/Session Control Function,I-CSCF, of an IP Multimedia Subsystem, IMS, comprising: receiving aSession Initiation Protocol, SIP, message; attempting to forward the SIPmessage to a Serving Call/Session Control Function, S-CSCF, of the IMSassigned to provide services to a user; if the attempt is determined tohave failed, sending a message to a Home Subscriber Server, HSS, of theIMS to request capabilities information for selecting a S-CSCF, therequest message also providing first information relating to the statusof the assigned S-CSCF; and on receipt of the capabilities informationfrom the HSS, selecting a replacement S-CSCF to provide services to theuser.

The method may comprise forwarding the SIP message to the replacementS-CSCF with second information relating to the status of the assignedS-CSCF.

According to a second aspect of the present invention there is provideda method for use by a Home Subscriber Server, HSS, of an IP MultimediaSubsystem, IMS, comprising: receiving from an Interrogating Call/SessionControl Function, I-CSCF, of the IMS a message to request capabilitiesinformation for selecting a Serving Call/Session Control Function,S-CSCF, the request message also providing first information relating tothe status of a S-CSCF assigned to provide services to the user; and independence upon the first information, setting an indicator maintainedat or accessible to the HSS so as to indicate an uncertain status inrelation to the assigned S-CSCF.

The method may comprise subsequently receiving a Session InitiationProtocol, SIP, message from a S-CSCF other than the assigned S-CSCF;checking the indicator to determine whether it is set to indicate anuncertain status in relation to the assigned S-CSCF and, if so,replacing the assigned S-CSCF with the other S-CSCF as being the S-CSCFassigned to provide services to the user; and updating the indicator soas not to indicate an uncertain status in relation to the newly-assignedS-CSCF.

The method may comprise rejecting the SIP message if it is determinedthat the indicator is not set to indicate an uncertain status inrelation to the assigned S-CSCF.

The method may comprise setting the indicator to indicate an uncertainstatus in relation to the assigned S-CSCF if the first informationsuggests that the assigned S-CSCF is at least to some extentnon-responsive.

According to a third aspect of the present invention there is providedmethod for use by a Serving Call/Session Control Function, S-CSCF, of anIP Multimedia Subsystem, IMS, comprising: receiving a Session InitiationProtocol, SIP, message from an Interrogating Call/Session ControlFunction, I-CSCF, of the IMS with second information relating to thestatus of a S-CSCF, different to the claimed S-CSCF, assigned to provideservices to a user; and storing in the S-CSCF receiving said message thereceived second information in relationship with information about saiduser held in said S-CSCF.

The first/second information may indicate that the assigned S-CSCF is atleast to some extent non-responsive.

The first/second information may identify the assigned S-CSCF.

The first/second information may provide an indication of a problembeing experienced by the assigned S-CSCF.

The SIP message may be a SIP Register message.

The SIP message may be a SIP Invite message.

The first information may be sent in a Diameter message.

The Diameter message carrying the first information may be aUser-Authorization Request, UAR, or a Location-Info-Request, LIR,message.

The second information may be sent in a SIP message.

The SIP message carrying the second information may be a REGISTER orINVITE message.

The first/second information may comprise information relating to anoperational status of the assigned S-CSCF.

The first/second information may comprise information relating to areason for the assigned S-CSCF being in the specified status.

According to a fourth aspect of the present invention there is providedapparatus for use in an IP Multimedia Subsystem, the apparatuscomprising means for performing a method according to any of the firstto third aspects of the present invention.

Where a message is stated as being from a user or sent to a particularnode, for example, it is to be understood that this is intended asincluding the case where the message is not sent directly from the useror to the particular node, but via other nodes as well.

According to a fifth aspect of the present invention there is provided aprogram for controlling an apparatus to perform a method according toany of the first to third aspects of the present invention or which,when loaded into an apparatus, causes the apparatus to become anapparatus according to the fourth aspect of the present invention. Theprogram may be carried on a carrier medium. The carrier medium may be astorage medium. The carrier medium may be a transmission medium.

According to a sixth aspect of the present invention there is providedan apparatus programmed by a program according to the fifth aspect ofthe present invention.

According to a seventh aspect of the present invention there is provideda storage medium containing a program according to the fifth aspect ofthe present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1, discussed hereinbefore, illustrates schematically theintegration of an IP Multimedia Subsystem into a 3G mobilecommunications system;

FIG. 2 is a block diagram illustrating a Data Model example used as abasis for the use cases described herein;

FIG. 3 illustrates failure at a S-CSCF Registration Procedure;

FIG. 4 illustrates failure at a S-CSCF Terminating Call Procedure;

FIG. 5 illustrates schematically a method and system according to anembodiment of the present invention corresponding to the scenariodescribed with reference to FIG. 3;

FIG. 6 illustrates schematically a method and system according to anembodiment of the present invention corresponding to the scenariodescribed with reference to FIG. 4;

FIG. 7 illustrates schematically some steps performed by an I-CSCF andan HSS in an embodiment of the present invention; and

FIG. 8 provides a table that defines the mapping between stage 2operations and stage 3 flows using the DIAMETER protocol.

DETAILED DESCRIPTION

Because of the lack of specified procedures in the current IMS standardas mentioned above, failure of an S-CSCF may result in incorrectprocessing of sessions, or not processing the sessions at all.

Before a description embodiments of the present invention, two use caseswill be described so explain the context in which embodiment of thepresent invention will operate. In these use cases, a S-CSCF is assumedto experience a persistent failure of some sort.

For simplicity, the Data Model example depicted in FIG. 2 will be takenas a base. It is assumed that there is an S-CSCF1 assigned to an IMSSubscription, i.e.:

-   -   either the IMPI1 (IP Multimedia Private User Identity) is        already registered/unregistered with another IMPU (IP Multimedia        Public User Identity), or    -   the IMPU1 was unregistered, or    -   any other IMPI within the IMS Subscription is registered or        unregistered

In a network where ALL queries are authenticated, a handover of S-CSCFswould be allowed, since the HSS would receive a Multimedia-Auth-RequestDiameter command from the reassigned S-CSCF, see 3GPP TS 29.228:

-   -   “If the new and previously assigned S-CSCF names sent in the        Multimedia-Auth-Request command are different and the        Multimedia-Auth-Request is not indicating synchronisation        failure (i.e. the request does not contain auts parameter), then        the HSS shall overwrite the S-CSCF name.”

However, when the query is not authenticated (usually there-registrations), the HSS would not receive a MAR Diameter command buta Cx-Put/Pull (i.e., a SAR command), and according to 3GPP these querieswould be rejected:

-   -   “If the new and previously assigned S-CSCF names sent in a        command other than the Multimedia-Auth-Request command are        different, then the HSS shall not overwrite the S-CSCF name;        instead it shall send a response to the S-CSCF indicating an        error.”

Two example use cases are described below to illustrate a networkfailure produced when the S-CSCF goes down.

Use Case 1: Registration/Re-Registration when S-CSCF has a PersistentFailure

The S-CSCF1 is serving the subscription1 when it goes to a restartcondition, or is experiencing some other form of disruption.

While S-CSCF1 is restarting, one of the following scenarios may occur:

-   -   The same user may re-register using the same Private User        Identity and Public User Identity    -   The same user may re-register another Public User Identity    -   Another user of the same subscription may re-register a Public        User Identity

An example sequence flow is illustrated in FIG. 3 and is as follows:

-   -   S1 The I-CSCF asks for the S-CSCF serving the user.    -   S2 The user is stored in HSS as served by S-CSCF1, The HSS        returns S-CSCF1.    -   S3 The I-CSCF forwards the REGISTER message to the received        S-CSCF1.    -   S4 Since S-CSCF1 is down (either being restarted or has a        persistent failure), the I-CSCF receives no answer and        re-attempts again.    -   S5 When the re-attempts threshold is reached, the I-CSCF pings        again to the HSS forcing the HSS to return the capabilities        instead of the stored S-CSCF1. This is done by means of        “Registration&Capabilities” attribute within the Cx-Query.    -   S6 The HSS returns the capabilities for the user.    -   S7 The I-CSCF selects a new S-CSCF2 and forwards the        registration query to it.    -   S8 The new S-CSCF2 pings the HSS in a Cx-Put/Pull message to        indicate that it is the S-CSCF serving the user and asking for        the profile.    -   S9 The HSS compares the stored S-CSCF and the new S-CSCF2 coming        in the received Cx-Put/Pull message.    -   S10 Since the two S-CSCFs are not the same, the HSS rejects the        registration query to the new S-CSCF2.

The consequence of this is that the user registration will neversucceed, since the HSS is mandated according to 3GPP to compare theS-CSCF allocated to serve the user (as stored in the HSS) and the S-CSCFthat pings the HSS in a Cx-Put/Pull message.

A similar problem would happen with a de-registration.

Use Case 2: Terminating Call when S-CSCF has a Persistent Failure

The S-CSCF1 is serving the subscription1 when it goes to a restartcondition, or is experiencing some other form of disruption.

While S-CSCF1 is restarting or has a persistent failure, a terminatingcall occurs for any user of the subscription1.

An example sequence flow is illustrated in FIG. 4 and is as follows:

-   -   T1 The I-CSCF asks for the S-CSCF serving the        user/subscription1.    -   T2 The HSS returns S-CSCF1, as stored.    -   T3 The I-CSCF forwards the INVITE message to the received        S-CSCF1.    -   T4 Since S-CSCF1 is down (either being restarted or has a        persistent failure), the I-CSCF receives no answer and        re-attempts again.    -   T5 When the re-attempts threshold is reached, the I-CSCF returns        back an error to the originating UE.        -   Note that for a terminating call 3GPP does not offer the            possibility to reallocate a new S-CSCF by asking for the            capabilities to the HSS.

The consequence of this is that terminating calls will never succeed,since the I-CSCF is not allowed according to 3GPP to ask for thecapabilities and to select a new S-CSCF.

With the above scenarios in mind, the basic idea underlying anembodiment of the present invention is to allow S-CSCF handover wheneverthere is persistent failure in a S-CSCF by:

-   -   Allowing reallocation of a new S-CSCF in terminating calls    -   Allowing the HSS to accept queries from a newly-allocated S-CSCF

The following sections describe how an embodiment of the presentinvention operates in use case descriptions provided above withreference to FIGS. 3 and 4.

Embodiment Applied to Use Case 1: Registration/Re-Registration whenS-CSCF has a Persistent Failure

In this scenario, as described previously, S-CSCF1 is servingsubscription1. S-CSCF1 has a persistent failure or is being restarted,or such-like. The I-CSCF receives a registration or re-registration fora user within subscription1.

The sequence flow in this embodiment is illustrated schematically inFIG. 5 and is as follows:

-   -   P1 The I-CSCF asks for the S-CSCF serving the user/subscription        to the HSS or the capabilities if no S-CSCF has been allocated        for the subscription1.    -   P2 Since the HSS has S-CSCF1 stored, it returns S-CSCF1.    -   P3 The I-CSCF tries to forward the REG to the S-CSCF1 but since        it is down, there is no answer.    -   P4 When the re-attempts threshold is reached, the I-CSCF asks        the HSS for the capabilities to select a S-CSCF, indicating that        S-CSCF1 is down.    -   P5 The HSS, at reception of such information, marks        subscription1 as “Not trustable” and returns the capabilities.    -   P6 The I-CSCF selects a new S-CSCF2 and forwards the REG message        to it.        -   An optimization of this forward message is for the I-CSCF to            indicate to the new S-CSCF2 that it has been reselected due            to a restart procedure. This information can be used by the            S-CSCF2 to pass the users back to the S-CSCF1 when it is up            again (if desired by the operator for load sharing reasons).            This information could be also stored in the HSS if desired.    -   P7 S-CSCF2 presents itself to the HSS by a Cx-Put/Pull. The HSS        checks that the user has a mark indicating that the stored        information is “Not trustable” so accepts the new S-CSCF2 by:        -   Assigning S-CSCF2 to all users of the subscription1 that had            S-CSCF1 stored; this keeps the 3GPP principle of having all            user of the same subscription being served by the same            S-CSCF.        -   Clearing the mark of not trustable data for the            subscription1.    -   P8 Registration call continues as for the normal 3GPP procedure.

This embodiment of the present invention differs from known proceduresin at least some of the following ways:

-   -   The mark in the Cx-Query (Step P4) to indicate:        -   the affected S-CSCF and        -   the reason: restart (or unreachable).    -   The flag in the HSS that indicates whether or not subscription        information is trustable; this allows the HSS whether or not to        accept users from a S-CSCF different from the stored one.    -   The indication in the SIP REGISTER message concerning:        -   the affected S-CSCF and        -   the reason: restart (or unreachable).        -   So that S-CSCF2 knows that it has been reassigned.

The procedure for de-registration would be equivalent to that describedabove since it is based on the same REG SIP message and same Cx-Put/Pullcommands.

Embodiment Applied to Use Case 2: Terminating Call when S-CSCF has aPersistent Failure

In this scenario, as described previously, S-CSCF1 is servingsubscription1. S-CSCF1 has a persistent failure or is being restarted,or such-like. The I-CSCF receives a terminating call for a user withinsubscription1.

The sequence flow in this embodiment is illustrated schematically inFIG. 6 and is as follows:

-   -   R1 The I-CSCF asks for the S-CSCF serving the user/subscription1        to the HSS or the capabilities if no S-CSCF has been allocated        for the subscription.    -   R2 Since the HSS has S-CSCF1 stored, it returns S-CSCF1.    -   R3 The I-CSCF tries to forward the INVITE message to the S-CSCF1        but since it is down, there is no answer.    -   R4 When the re-attempts threshold is reached, instead of sending        back an error, the I-CSCF asks the HSS for the capabilities to        select a S-CSCF, indicating that S-CSCF1 is down.    -   R5 The HSS, at reception of such information, marks        subscription1 as “Not trustable” and returns the capabilities.    -   R6 The I-CSCF selects a new S-CSCF2 and forwards the INVITE        message to it.        -   An optimization of this forward message is for the I-CSCF to            indicate to the new S-CSCF2 that it has been reselected due            to a restart procedure. This information can be used by the            S-CSCF2 to failover this users to the S-CSCF1 when it is up            again (if desired by the operator due to load sharing            reasons). This information could be also stored in the HSS            if desired.    -   R7 The S-CSCF2 presents itself to the HSS by a Cx-Put/Pull. The        HSS checks that the user has a mark indicating that the stored        information is “Not trustable”, and so accepts the new S-CSCF2        by:        -   Assigning S-CSCF2 to all users of the subscription1 that had            S-CSCF1 stored.        -   Clearing the mark of not trustable data for the whole            subscription.    -   R8 The terminating call continues as for the normal 3GPP        procedure.

This embodiment of the present invention differs from known proceduresin at least one of the following ways:

-   -   The new content of the Cx-LocationQuery (step R4):        -   to indicate that the contacted S-CSCF is down S-CSCF            (optionally, it can further indicate a reason, such as            “restart” or “unreachable”), and        -   to request the HSS the capabilities to select a S-CSCF.    -   The flag in the HSS that indicates whether or not subscription        information is trustable; this allows the HSS to decide whether        or not to accept users from a S-CSCF different from the stored        one.

General

The above description can be summarised by illustrating in general termsin FIG. 7 the steps that are performed by the I-CSCF (left-hand side)and HSS (right-hand side) nodes. It will be appreciated that the variouselements illustrated in each of FIG. 7 can also be considered torepresent components of an apparatus having those respective functions,and FIG. 7 is to be interpreted accordingly as also illustrating I-CSCF(left-hand side) and HSS (right-hand side) apparatus.

A system, method and apparatus according to an embodiment of the presentinvention allows hand-over to a new S-CSCF when the previously-assignedone has failed.

This is achieved by allowing the I-CSCF to inform the HSS that a faultoccurred with the previously-assigned S-CSCF in any of the queries itsent to the HSS, for example: “Cx-Query” (UAR) for registration events,and “Cx-Location-Query” (LIR) for terminating calls. The HSS then storesa fault mark of some sort in relation to the previously-assigned S-CSCF,which permits it to accept further requests from the newly assignedS-CSCF.

FIG. 8 provides a table that defines the mapping between: stage 2operations (illustrated in the drawings described above), and stage-3flows (using the DIAMETER protocol to implement the stage 2 operations).The table has been reproduced from 3GPP spec TS 29.228 V7.3.0 (September2006).

It will be appreciated that operation of one or more of theabove-described components can be controlled by a program operating onthe device or apparatus. Such an operating program can be stored on acomputer-readable medium, or could, for example, be embodied in a signalsuch as a downloadable data signal provided from an Internet website.The appended claims are to be interpreted as covering an operatingprogram by itself, or as a record on a carrier, or as a signal, or inany other form.

It will also be appreciated by the person of skill in the art thatvarious modifications may be made to the above-described embodimentswithout departing from the scope of the present invention as defined bythe appended claims. In particular, it will be appreciated that,although described in relation to a Universal Mobile TelecommunicationsSystem having an IP Multimedia Subsystem, the present invention is alsoapplicable to other types of network.

1. A method for use by an Interrogating Call/Session Control Function,CSCF, of an IP Multimedia Subsystem, IMS, comprising: receiving aSession Initiation Protocol, SIP, message; attempting to forward the SIPmessage to a Serving Call/Session Control Function, S-CSCF, of the IMSassigned to provide services to a user; if the attempt is determined tohave failed, sending a message to a Home Subscriber Server, HSS, of theIMS to request capabilities information for selecting a S-CSCF, therequest message also providing first information relating to the statusof the assigned S-CSCF; and on receipt of the capabilities informationfrom the HSS, selecting a replacement S-CSCF to provide services to theuser.
 2. A method as claimed in claim 1, comprising forwarding the SIPmessage to the replacement S-CSCF with second information relating tothe status of the assigned S-CSCF.
 3. A method for use by a HomeSubscriber Server, HSS, of an IP Multimedia Subsystem, IMS, comprising:receiving from an Interrogating Call/Session Control Function, I-CSCF,of the IMS a message to request capabilities information for selecting aServing Call/Session Control Function, S-CSCF, the request message alsoproviding first information relating to the status of a S-CSCF assignedto provide services to the user; and in dependence upon the firstinformation, setting an indicator maintained at or accessible to the HSSso as to indicate an uncertain status in relation to the assignedS-CSCF.
 4. A method as claimed in claim 3, comprising: subsequentlyreceiving a message from a S-CSCF other than the assigned S-CSCF;checking the indicator to determine whether it is set to indicate anuncertain status in relation to the assigned S-CSCF and, if so,replacing the assigned S-CSCF with the other S-CSCF as being the S-CSCFassigned to provide services to the user; and updating the indicator soas not to indicate an uncertain status in relation to the newly-assignedS-CSCF.
 5. A method as claimed in claim 4, comprising rejecting the SIPmessage if it is determined that the indicator is not set to indicate anuncertain status in relation to the assigned S-CSCF.
 6. A method asclaimed in claim 3, comprising setting the indicator to indicate anuncertain status in relation to the assigned S-CSCF if the firstinformation suggests that the assigned S-CSCF is at least to some extentnon-responsive.
 7. A method for use by a Serving Call/Session ControlFunction, S-CSCF, of an IP Multimedia Subsystem, IMS, comprising:receiving a Session Initiation Protocol, SIP, message from anInterrogating Call/Session Control Function, I-CSCF, of the IMS withsecond information relating to the status of a S-CSCF, different to theclaimed S-CSCF, assigned to provide services to a user; and storing inthe S-CSCF receiving said message the received second information inrelationship with information about said user held in said S-CSCF.
 8. Amethod as claimed in claim 2, wherein the first/second informationindicates that the assigned S-CSCF is at least to some extentnon-responsive.
 9. A method as claimed in claim 2, wherein thefirst/second information identifies the assigned S-CSCF.
 10. A method asclaimed in claim 2, wherein the first/second information provides anindication of a problem being experienced by the assigned S-CSCF.
 11. Amethod as claimed in claim 1, wherein the SIP message is a SIP Registermessage.
 12. A method as claimed in claim 1, wherein the SIP message isa SIP Invite message.
 13. A method as claimed in claim 1, wherein thefirst information is sent in a Diameter message.
 14. A method as claimedin claim 13, wherein the Diameter message carrying the first informationis a User-Authorization Request, UAR, or a Location-Info-Request, LIR,message.
 15. A method as claimed in claim 1, wherein the secondinformation is sent at some stage in a SIP message.
 16. A method asclaimed in claim 15, wherein the SIP message carrying the secondinformation is a REGISTER or INVITE message.
 17. A method as claimed inclaim 2, wherein the first/second information comprises informationrelating to an operational status of the assigned S-CSCF.
 18. A methodas claimed in claim 2, wherein the first/second information comprisesinformation relating to a reason for the assigned S-CSCF being in thespecified status.
 19. An apparatus for use in an IP MultimediaSubsystem, the apparatus comprising means for performing a method asclaimed in claim
 1. 20. A program for controlling an apparatus toperform a method as claimed in claim
 1. 21. A program which, when loadedinto an apparatus, causes the apparatus to become an apparatus asclaimed in claim
 19. 22. A program as claimed in claim 20, carried on acarrier medium.
 23. A program as claimed in claim 22, wherein thecarrier medium is a storage medium.
 24. (canceled)
 25. An apparatusprogrammed by a program as claimed in claim
 20. 26. A storage mediumcontaining a program as claimed in claim
 20. 27. A method as claimed inclaim 3, wherein the first information indicates that the assignedS-CSCF is at least to some extent non-responsive.
 28. A method asclaimed in claim 7, wherein the second information indicates that theassigned S-CSCF is at least to some extent non-responsive.
 29. A methodas claimed in claim 3, wherein the first information identifies theassigned S-CSCF.
 30. A method as claimed in claim 7, wherein the secondinformation identifies the assigned S-CSCF.
 31. A method as claimed inclaim 3, wherein the first information provides an indication of aproblem being experienced by the assigned S-CSCF.
 32. A method asclaimed in claim 7, wherein the second information provides anindication of a problem being experienced by the assigned S-CSCF.
 33. Amethod as claimed in claim 7, wherein the SIP message is a SIP Registermessage.
 34. A method as claimed in claim 7, wherein the SIP message isa SIP Invite message.
 35. A method as claimed in claim 3, wherein thefirst information is sent in a Diameter message.
 36. A method as claimedin claim 35, wherein the Diameter message carrying the first informationis a User-Authorization Request, UAR, or a Location-Info-Request, LIR,message.
 37. (canceled)
 38. A method as claimed in claim 3, wherein thefirst information comprises information relating to an operationalstatus of the assigned S-CSCF.
 39. A method as claimed in claim 7,wherein the second information comprises information relating to anoperational status of the assigned S-CSCF.
 40. A method as claimed inclaim 3, wherein the first information comprises information relating toa reason for the assigned S-CSCF being in the specified status.
 41. Amethod as claimed in claim 7, wherein the second information comprisesinformation relating to a reason for the assigned S-CSCF being in thespecified status.
 42. An apparatus for use in an IP MultimediaSubsystem, the apparatus comprising means for performing a method asclaimed in claim
 3. 43. An apparatus for use in an IP MultimediaSubsystem, the apparatus comprising means for performing a method asclaimed in claim 7.